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ABSTRACT 


The intent of this thesis is to gain insight into launch and test range requirements 
in order to determine transitional architectures by using a systems engineering 
methodology developed at the Naval Postgraduate School. The range is a weapon system 
that has many characteristics of an automated information system with each function 
having its own timing and bandwidth requirements. The sensors considered are those left 
after the range begins using GPS metric tracking for all launch vehicles. The analysis 
focuses on comparing the use of current data formats to an Internet Protocol version 6 
(IPv6) standard by considering data availability and timeliness as design parameters. 
Sensors should be compatible with the data network rather than with legacy formats since 
data is not transported in the legacy formats. Devices requiring a legacy format need a 
converter to consume data from the network. The analysis is an accounting of throughput 
required at various nodes on the data network and estimates of data latency along critical 
data links. The conclusion is that the current range architecture is able to support GPS 
metric tracking and that an IPv6 network is a viable option that moves the range toward 
compliance with the Operational Requirements Document. 
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I. 


INTRODUCTION 


A. BACKGROUND 

The United States Air Foree is responsible for operating and sustaining the 
nation’s Spaeelift Ranges. They are the Eastern Range (ER) in Elorida with launeh 
complexes at Cape Canaveral and Kennedy Space Center, and the Western Range (WR) 
with launch complexes at Vandenberg Air Eorce Base. Together, the ER and WR 
comprise the current Eaunch and Test Range System (ETRS). 

The Eastern Range is operated by the Air Eorce’s 45th Space Wing (45 SW), and 
the 30th Space Wing (30 SW) operates the Western Range. Space Missile Systems 
Center (SMC) is responsible for both sustainment and new acquisitions. These 
responsibilities have been assigned to the Eaunch and Ranges Range Group under the 
Eaunch and Range Systems Wing. 

The primary mission of the ETRS is to support both routine and responsive 
spaeelift for DoD, other US government agencies (NASA, NOAA and intelligence 
community) and commercial interests. The secondary and tertiary missions are Test and 
Evaluation, and supporting the Space Surveillance Network (SSN) respectively. 

1. Eastern Range 

The 45th Space Wing, headquartered at Patrick Air Eorce Base (PAEB), conducts 
spaeelift and missile test operations at the ER on the central east coast of Elorida (see 
Eigure 1). 
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ER instrumentation sites are loeated at NASA’s Kermedy Space Center (KSC), 
Cape Canaveral Air Force Station (CCAFS), PAFB, Melbourne Beach Optical Tracking 
Annex, Malabar Annex, Jonathan Dickinson Missile Tracking Annex (JDMTA), Antigua 
Air Station in the eastern Caribbean Sea, and Ascension Auxiliary Airfield in the South 
Atlantic Ocean. For North Easterly space launches, the ER extends north to New 
Hampshire Tracking Station and Argentia in Newfoundland, Canada, and includes a 
midpoint location at Wallops Islands, Virginia (NASA facility). Eaunch sites on KSC 
and CCAFS are capable of supporting most launch azimuths from 34° to 112° with some 
excluded for safety restrictions. 

2. Western Range 

Headquartered at Vandenberg Air Force Base (VAFB), the 30th Space Wing 
conducts spacelift and missile test launches at the WR on the central coast of California 
(Figure 2). 


2 




WR instrumentation sites are located along the Pacific coast at Pillar Point Air 
Force Station, VAFB, Anderson Peak, Santa Ynez Peak, Laguna Peak, and Point Mugu. 
The WR supports southern trajectory space launches capable of achieving polar orbits. 
Launch sites on VAFB are capable of supporting launch azimuths from 147° to 286°. In 
conjunction with other Major Range and Test Facility Base (MRTFB) activities, the WR 
provides continuous instrumentation coverage for ballistic missile test launches into 
target areas in the Pacific Ocean. Additionally, the WR provides operational support for 
the West Coast Offshore Operating Area (WCOOA), creating an aeronautical, and guided 
and unguided missile test corridor along the Pacific coast from the Mexican to the 
Canadian borders. The WR supports satellite launches into polar orbits, intercontinental 
ballistic missile tests. Missile Defense Agency (MDA) activities, and aeronautical tests. 
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3. 


Future Range Architectural Planning 


The Future Range Architeeture Team (FRAT) was assembled to provide a range 
roadmap that moves from the eurrent range arehitecture to a vision for 2020. The team 
ineluded representatives from Headquarters Air Foree Spaee Command (operations and 
requirements direetorates), Launeh and Ranges Systems Wing, 30th Spaee Wing, 45th 
Spaee Wing, Aerospaee Corporation, and ENSCO. 

The lynehpin of the FRAT’s proposed arehitecture is a net-ready infrastructure 
built on the Internet Protocol version 6 (IPv6) standard, which is interoperable with the 
DoD information sharing environment known as the Global Information Grid (GIG). 
This would replace the current Cellworx® core with a modern and sustainable 
communications network. 

Since the time the FRAT developed their proposal, considerable budget cuts were 
projected. The commander of Air Force Space Command charged the Launch Enterprise 
Team (LET) with finding potential savings in the launch enterprise. Since then, the 
vision of the range architecture has been the subject of vigorous debate. 

B. PURPOSE 

The intent of this thesis is to gain insight into LTRS requirements for determining 
reasonable transitional architectures. 

Currently the Spacelift Ranges use a strategy of acquiring modern instrumentation 
and making it backward compatible to the current range infrastructure. This approach 
was a driver in the cost and complexity of employing the Massachusetts Institute of 
Technology Lincoln Laboratory (MIT-LL) developed radar known by the acronym 
ROSA, which stands for Radar Open Systems Architecture. Bringing ROSA to the 
Spacelift Ranges required elaborate interfacing to slow the data and conform to the 
legacy data frames in order to interface with the current range infrastructure. Other 
instrumentation modernization efforts are underway and they will likely have a number 
of backward compatibility requirements. Determining how to break out of the backward 
compatibility mode gives rise to the research questions posed in this thesis. 
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Since the range needs to continue to support operations during the transition, there 
may be interim hybrid configurations used during the evolution. Perhaps a hybrid range 
eonsisting of various sub-networks of net-ready sensors made backward compatible as a 
group is more effective. Perhaps a modernized range will be built alongside the legaey 
range with sensors feeding both the legacy and modem networks. After a series of dual 
mode operations the legaey network can be turned off. 

C. RESEARCH QUESTIONS 

Question 1: Should the Spaeelift Ranges migrate their data networks to an IPv6 
standard as proposed by the Future Range Architeeture Team? 

Question 2: In modernizing the range data network, is it more advantageous to 
make legaey components forward compatible or to make modern eomponents backward 
compatible? 

D. BENEFITS OF STUDY 

This study proposes eriteria and methodology to evaluate different range network 
configurations and data flow schemes. The eriteria are data availability, which is whether 
the network has the capacity to transport the required data, and timeliness, which is 
whether the data transport is done within the allowable time. The method for evaluating 
availability is to determine the required volume of data and eompare it to the capaeity of 
the network switches and data links. The methodology for evaluating timeliness is to 
determine the lateney of various data links by adding the latency of each step of the data 
transport proeess. The intended benefit is to give decision makers a framework for 
eonsidering the merits of projects that evolve the range to the planned future arehitecture. 

E. SCOPE AND METHODOLOGY 

This thesis proposes interim configurations that the Eastern Range might assume 
during its evolution. The candidate interim configurations are eonsistent with the visions 
of the LET in that the range footprint reflects its plan with different networking schemes. 
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The candidate configurations are retaining the current network or upgrading it according 
to the FRAT plan. Operational scenarios are identified and the candidate configurations 
are evaluated in terms of system design parameters. 

F. ORGANIZATION AND SUMMARY OF STUDY 

1. Background Information 

This thesis begins with a discussion of the strategy for gathering background 
information for the analysis. Broad topic areas are identified along with a discussion of 
potential sources of information. The basic topic areas are 1) systems engineering 
methodology, 2) range requirements, 3) Eastern Range architecture, 4) Eastern Range 
operational configurations, and 5) communications networks. The strategy discussion is 
followed by a summary of the information gathered. The information is grouped in the 
same topic areas. 

2. Analysis and Results 

The analysis of the candidate configurations and the results are organized as a 
discussion of how each step of the system engineering methodology is applied to 
studying the Eastern Range. The analysis focuses on comparing the current network 
structure to a proposed network based on an IPv6 standard. The design parameters are 
availability and timeliness. Both of these are judged from a range safety perspective. 

Availability is considered in terms of the network capacity to move all of the 
required data. A throughput model is used to determine how much bandwidth is 
required. Timeliness requirements are established to meet the range safety requirements. 
Timeliness is evaluated by considering the data latency introduced as the data flows 
through the network. The results of this analysis are considered in terms of how range 
systems are made to be interoperable with the network and how that interoperability 
might be achieved. 


6 



3. 


Conclusions and Recommendations 


The range is generally considered a weapon system sensor network and is often 
viewed as a hub and spokes topology with an operations center at the hub and the sensors 
on the spokes. Another point of view useful for determining range functional 
requirements is one that considers the range as an Automated Information System (AIS) 
where data comes on to a network and consumers access it. This viewpoint focuses on 
the core network, which would be the hub from the sensor net point of view. Both 
viewpoints reflect functions the range needs to perform. Each function has its own 
timing and availability (bandwidth) requirements that converge on the core network; the 
data network thus needs to be the focus of architectural decisions. In particular, the 
sensor interfaces need to be defined for compatibility with the data network rather than 
with legacy data formats, which are incompatible with the data network. 

The current range network has the bandwidth for the network traffic required to 
function as a sensor network and as an Automated Information System. The limiting 
factor for the network is the data link to JDMTA. This link is especially important 
because all GPS metric tracking data is processed at JDMTA. The GPS data is contained 
in the telemetry stream. At this point, the telemetry stream needs to be divided, so only 
the portion carrying the GPS data is sent for processing at JDMTA. The commercial 
leased lines do not have the capacity to handle the entire telemetry stream. Another 
network traffic flow that is worth considering is the data link to the telemetry site TEL 
IV. TEL IV is the where the telemetry streams are evaluated to determine which stream 
to provide to the range customer. Both the current network and an IPv6 based network 
can meet the timeliness requirements for range safety. The biggest source of data latency 
comes from packaging data into cells for transport on the network. The IPv6 network 
would require data to be sent in IP packets. The time needed for either operation is 
dependent on the rate data flows into the device that packages it because the cells (or 
packets) cannot be assembled until the entire data frame is received. This makes 
adherence to legacy data standards (240-bit data frames transported at 2.4 or 4.8 Kbps) a 
significant source of latency. 
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Sensors should be built to be eompatible with the data network rather than with 
the data rate and format of the deviee eonsuming the data. Since data is not transported 
on the network in the legacy data formats, any device that requires a legacy data format 
must have a converter to consume data from the network. Requiring new sensors to 
output a legacy data format means that output has to be converted to a cell (or packet) for 
it to be sent on the data network. If the sensor could have output data in a form 
compatible with the network, the steps required to produce the legacy format add 
unnecessary complexity and latency. 

The current range architecture seems able to support a move to GPS metric 
tracking. Additionally, this analysis concludes that an IPv6 based range data network is a 
viable option that moves the range toward compliance with the Operational Requirements 
Document (ORD). However, supportability and interoperability are significant factors in 
choosing an architecture. Consideration of those factors is beyond the scope of this 
thesis. 
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II. RESEARCH 


A. INTRODUCTION 

Learning about the Spacelift Ranges proved to require a great deal of researeh. 
Studying a few doeuments led to asking people questions, whieh in turn generated 
referrals to various experts. The experts often reeommended studying other doeuments, 
drawing, and handbooks, whieh lead to more questions and so on. 

Creating a system of systems out of the range assets is largely a matter of 
networking. The range network is the foeus of this analysis. 

B. METHODOLOGY 

The researeh methodology is to review published work that deseribes and 
diseusses applieation of a systems engineering methodology developed at the Naval 
Postgraduate Sehool (Osmundson & Huynh, 2005). The next area of investigation is the 
range requirements. Sinee the range is an Air Foree aequisitions program, requirements 
are formally doeumented. Interviews with range engineers and operators give additional 
insight into the requirements. These sources and range operational capability documents 
provide information on the current range architectures. Current thinking on the future of 
the range architecture is revealed in presentations given by various groups working in Air 
Force Space Command. Interviews are another valuable source of information. 

Another research objective is to gain an understanding of information networks. 
This is done by reviewing journal articles, range operator training materials, industry 
standards, and through conducting interviews. 

C. RESEARCH 

I. Systems Engineering 

A practical method of analyzing a system of systems is espoused in (Osmundson 

& Huynh, 2005). This method applies effectively to the Spacelift Ranges since it is 
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concerned with systems that have been developed and still funetion as standalone 
systems. It is well suited to systems sueh as the Spacelift Ranges whose success is 
dependent on process timeliness. The method involves a sequenee of analyses, modeling, 
and simulations. The seven steps of the method are as follows: 

• Development of system of systems seenarios and operational architectures 

• Identifieation of system of systems threads 

• Representation of operational architectures in a unified modeling language 
(UML)-like format 

• Identifieation of systems of systems design parameters and factor levels 

• Transformation of UML-like format representation into exeeutable models 

• Application of design of experiments 

• Simulation runs and analysis of results 

2. Range Requirements 

The range requirements are captured in the Operational Requirements Doeument 
(ORD) (Headquarters Air Foree Spaee Command, DRDS, 2003). Particular attention is 
given to interoperability as discussed in Section 1.4.3 Command, Control, 
Communications, Computer, Intelligence, Surveillance, and Reeonnaissance (C4ISR) 
Operational Concept. The ORD offers an operational view 1 (OV-1) of the LTRS listing 
the wide variety of agencies and supporting ranges that need to interface with the 
Spacelift Ranges and the connections that join the range subsystems together to create a 
system of systems. The ORD, again from Section 1.4.3.3, specifies that the LTRS must 
have interfaces for connectivity to digital and analog information links, satellite and voice 
communications circuits. Additionally, the LTRS must operate within the DoD 
information sharing environment known as the Global Information Grid (GIG). 

3. Range Architecture 

Deliberations on the range architecture seem to eenter on the number and 
placement of what this analysis called the end items, which are the sensors necessary to 
perform the range tracking functions. The evolution of the range arehitecture is also 
discussed in terms of two maturing concepts that may ehange the way range functionality 
is achieved. 
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Starting with a review of the range function, the FRAT (FRAT, 2007) identities 
the required functionality as: 

• Flight Control (command destruct, flight operations, flight analysis, 
vehicle control) 

• Space vehicle (SV)/launch vehicle (LV) health and status (performance, 
telemetry) 

• Tracking (debris, launch vehicle position, staging events) 

• Imaging (documentary—media, public affairs, engineering analysis, event 
reconstruction) 

• Command, Control, Communication and Timing-C3T (voice, data, 
video, timing, range operations management) 

• Data Handling (data products, planning and scheduling) 

• Area Surveillance (detection & assessment of air, sea, and rail 
encroachments) 

• Weather (observation, analysis, forecasting) 

The functions whose evolution will most impact the range footprint (end item 
assets) are Tracking and Flight Control, particularly the command destruct part of Flight 
Control. 

In the near future, GPS metric tracking will be utilized on a number of launch 
vehicles. Currently the GPS data is received on a telemetry stream, and so is the Inertial 
Guidance System (IGS) data. They fulfill the requirement of having two independent 
sources of metric tracking data. Radar and optics (on the Eastern Range at least) are also 
viable sources of metric track data. As GPS tracking is fully implemented, radar and 
optics will no longer be considered range safety mandatory and will instead provide 
imaging data and back up tracking data, as well as debris tracking. 

Another concept that will shape the range is the evolution of Autonomous Flight 
Termination Systems (AFTS). Flight termination is currently done with a person in the 
loop. The tracking data is displayed for a person to consider in determining whether to 
command the vehicle to destruct. The commands are sent using ground based 
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antennas at a variety of points along the range. When AFTS are used on every roeket 
launehed, the range can divest the ground based command systems and possibly the 
systems that generate metric tracking data. 

a. Range Sensors 

The number and the placement of range sensors are often the focus of 
discussion about the range architecture. A list of the current range assets is shown in 
Table 1, which depicts a distinction between enabling equipment necessary for end items 
(sensors) to operate as part of the range system. For example, the radars and telemetry 
sites are end items that directly result in range capability to cover a particular mission. 
The communications infrastructure and items like voice communications are all 
necessary, irrespective of the number of end items because they enable the subsystems to 
be joined into the range system. Table 1 shows the FRAT and LET assets considered 
necessary while working under the assumption that GPS metric tracking would replace 
radar as a range safety metric tracking source. The LET went on to develop preliminary 
planning concepts for a range using AETS. 

In Table 1 ‘X’ indicates equipment (rows) used in the given plan 
(columns) and ‘D’ denotes assets to be divested. Enabling equipment lines are grey. 


Table 1. Eastern Range Assets Under Various Plans 



Current 

Enabler End Item 

FRA 

T 

block 

1 

End 

Item 

LET 

Pre GPS 

LET 

GPS 

AFTS 
used 
End Item 


ADD GPS metric trackinq 



X 


X 

X 


1.16 


X 

D 

X 

D 


o 

Q. 

19.39 (MOTR) 


X 

X 

D 

D 


m 

LL 

19.17 


X 

D 

X 

D 


< 

Q. 

19.14 


X 

X 

D 

D 


o 

rr\ 

0.14 


X 

X 

X 

X 


Uj 

is; 

SPARC 

X 






CO 

LL 

FCA Control 

X 






< 

o 

FCA Van #1,2 

X 






o 

TAA-3C 


X 

X 

X 

X 

X 
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Current 

Enabler End Item 

FRA 

T 

block 

1 

End 

Item 

LET 

Pre GPS 

LET 

GPS 

AFTS 
used 
End Item 


TAA-24A 


X 

X 

X 

X 

X 


AFSCN Data Distribution 

X 







Data Acquisition and Processing 

X 







Dispiay 

X 







Record 

X 







Separation 

X 







CTPS 

X 







TRG 

X 







9M-1,2 

X 







4.3M 

X 







ACME 

X 







CAPE1B 


X 

X 

X 

X 

D 


CAPE 1A 


X 

X 

X 

X 

D 


CCRS 

X 







Anaiog Voice 

X 







Cabie Piant and Conditioning 

X 







Commerciai Leased Lines 

X 







Digitai Voice-XY 

X 







NASCOM 

X 







Wideband 

X 







CORE 

X 







Data Transmission 

X 







Digitai Voice 

X 







Inteisat SATCOM 

X 







M365 INMARSAT 

X 







Microwave 

X 







TMS 

X 







AMP S-A,B 

X 







MSC 

X 







DBS 

X 







DRSD 

X 







FOV1-A,B 

X 







RSAS 

X 







Count, Timing, and Controi 

X 







ATOTS 1,2 


X 

X 

X 

X 

X 


MIGOR 


X 

X 

X 

X 

X 

CO 

o 

CINE 401-403 


X 

D 

X 

D 

D 

Q. 

O 

CINE 404-407 


X 

D 

D 

D 

D 


Playalinda DOAMS 


X 

X 

X 

X 

X 


PAFB DOAMS 


X 

X 

X 

X 

X 

Q $ 

28.14 


X 


D 

D 

D 





1= cc 

LU £= 





TAA-50-1 X XX moved 
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Current 

Enabler End Item 

FRA 

T 

block 

1 

End 

Item 

LET 

Pre GPS 

LET 

GPS 

AFTS 
used 
End Item 








CCAFS 

TAA-50-2 


X 

X 

X 

moved 

CCAFS 

TAA-50-3 


X 

X 

X 

Eliminate 

TAA-50-4 


X 

X 

X 

ACME 

X 




COMMAND 


X 

X 

X 

Cable Plant and Conditioning 

X 




CORE 

X 




Data Transmission 

X 




Microwave 

X 




TMS 

X 




TORS (GPS tracking) 


X 

X 

X 

moved 

CCAFS 

Count and Timing 

X 





Antigua/St. Thomas 

91.14 


X 

D 

D 

D 

D 

91.134 


X 

D 

D 

D 

D 

TAA-3C 


X 

X 

X 

X 

X 

TAA-8A 


X 

X 

X 

X 

X 

ACME 

X 






COMMAND 


X 

X 

D 

D 

D 

Cable Plant and Conditioning 

X 






CORE 

X 






Data Transmission 

X 






Digital Voice 

X 






Intelsat SATCOM 

X 






TMS 

X 






Count and Timing 

X 






Argentia 

53.17 


X 

Support with 
mobiles 

Support with 
mobiles 

Support with 
mobiles 

Eliminate 

ACME 

X 


COMMAND 


X 

Data Transmission 

X 


Cable Plant and Conditioning 

X 


TMS 

X 


Station Count and Timing 

X 


ASC 

12.18 


X 

D 

D 

D 

D 

12.15 


X 

X 

X 

X 

X 

TAA-3C-1 


X 

D 

D 

D 

D 

TAA-3C-2 


X 

D 

D 

D 

D 

Station Count and Timing 

X 
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b. Range Network 


The FRAT plan for the range arehiteeture looks beyond the end item 
assets to focus on the data network. It proposes an architecture built on an IPv6 network 
ring that would allow the range to be DoD GIG complaint. GIG compliance is an ORD 
requirement found in Section 1.4.3.3. The FRAT presents GIG compliance as one of the 
pillars of their Block 1 architecture. The five pillars are: 1) comply with the DoD Joint 
Technical Architecture by using IPv6, 2) become compatible with the GIG, 3) use cluster 
computing, 4) have massive storage for high bandwidth digital imaging, and 5) provide 
new software based telemetry receivers and recorders (Slide 20, FRAT, 2007). 

The legacy communications network is largely based on Cellworx® 
switches which are designed for use in an asynchronous transfer mode (ATM); however, 
the network is setup for Time Division Multiplexing (TDM) (Bryant, 2008) using circuits 
that are static during a launch operation. The Eastern Range network uses a ring topology 
connecting four primary facilities. The facilities are the Range Operations Control 
Center (ROCC), XY Facility, Southwest Terminal Building (SWTB), and the East 
Terminal Building (ETB). 

The core itself is shown as Ring 1 and Ring 2 in the CCAES CORE - Data 
Elow illustration that is presented in the Eastern Range Instrumentation Handbook 
(Computer Sciences Raytheon, 2008), shown in Eigure 3. Table 2 explains the path 
speeds (Computer Sciences Raytheon, 2008). 
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CCAFS CORE — Datd Flow 



* r«t all &RIM or Non ERIH taciKias are raiiTesaned in this dia^rain 


Figure 3. Eastern Range Core Network (Fig. 1-1 in Computer Seienees Raytheon, 

2008) 


Table 2. Connection Speeds (Table 3.1-1 in Computer Sciences Raytheon, 2008) 


SIGNAL LEVEL 

DATA RATE (Mbps) 

COMMENT 

DS-0 

0.064 

Standard voice channel 

DS-1 or T-1 

1.544 

24 Standard voice channels 

DS-3 

44.736 

28DS-1S 

STS-1 (OC-1) 

51.84 

DS-3 with ATM/SONET overhead 

OC-3 

155 

3 OC-ls 

OC-12 

622 

12 0C-1S 

OC-48 

2488 

48 OC-ls 
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The core consists of five subsystems: 1) ATM Core, 2) Core Access 
Concentrators 3) Core Data Subsystem, 4) Core Video Subsystem, and 5) Inverse 
Multiplexers (IMUX) (Computer Sciences Raytheon, 2008). 

The core rings are designed to be fault tolerant in that they react to a node 
failure by routing the network traffic around the ring in the opposite directions. The only 
capability lost is the ability to add or remove data from the core via the failed node. The 
Core Access Concentrators are located at each of the nodes to adapt a variety of non- 
ATM traffic to an ATM format for transfer onto the core rings. The Core Data subsystem 
serves as an interface for handling telemetry data. The Core Video subsystem is capable 
of digitizing and managing videos using the core for transport to end users. The IMUX 
subsystem provides the interface between the ROCC Wide Area Network Interface Units 
(WANIU) and the JDMTA WANIU. 

The Eastern Range Instrumentation Handbook includes a section on 
limitations of the core. One limitation is that the data latency for the 2.4 Kbps 
synchronous circuit is approximately 60 milliseconds. Its impact is that the ATM core 
cannot be used to directly transport this data, so it must be aggregated into cells 
compatible with T-1 circuits for transport. There is also significant latency in the video 
system. For the 5 MHz bandwidth rate the latency is 1244 milliseconds, for 10 MHz it is 
827 milliseconds, and at 15 MHz the latency is 717 milliseconds (Computer Sciences 
Raytheon, 2008). 


c. Range Safety Systems 

The range safety systems include the system that processes and displays 
metric tracking and telemetry home vehicle performance data. They also provide target 
acquisition data to the command, telemetry and radar systems. The system that provides 
for termination of an errant vehicle is also a range safety system. 

Flight Operations Version 1 (FOVl) is the primary system that processes 

trajectory source data. Two independent FOVl systems, designated FOVl-A and FOVl- 

B, are used. A tertiary processor, the Distributed Range Safety Display (DRSD) system 

is included to mitigate the risk of a latent software defect in FOVl-A and FOVl-B, which 
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run the same software. These systems generate flight path, predicted Instantaneous 
Impact Point (IIP) displays, and other displays that are needed to determine the risk of 
violating pre-defined mission rules. 

The FOVl-A system also has an additional Mission Continuation Display 
(MCD) to monitor vehicle performance and provide an independent, telemetry only IIP 
display. The MCD design and programming language is completely different from the 
two FOVl systems as a safe guard against software Single Points of Failure (SPOF). 

The FOVl-A, FOVl-B, and DRSD systems provide designate data on the 
High Density Data (HDD) lines to instrumentation sites via the Data Buffer System. The 
Designate Source Select Switch (DSSS) is used to assign which system’s HDD output to 
the remote sites. That decision is made by the Acquisition Data Processor (ADP) 
operator. 

Data frames are synchronized before entering FOVl by buffering them in 
100-millisecond intervals (Thomas, 2008). Radar and optics data can be up to one 
second old and telemetry data can be up to 1.2 seconds old (Richards, 2008). Radar and 
optics data frames include a data bit known as the “track-bit.” Additionally a quality-bit, 
known as a “Q bit,” is available to indicate that the track is considered to be of good 
quality. FOVl can use data from a source irrespective of the Q-bit, but generally will not 
use data if the Q-bit is not set. Telemetry data quality is judged with frame 
synchronization indicators. The FOVl display operator has the option of rejecting a data 
source. This might be done if the data seems to be “noisy” or if the sensor is under test 
and evaluation (Thomas, 2008). 

FOVl inputs are tabulated in Table 3. Different sensors use different 
coordinate systems. Optic trackers only measure angles, so several trackers are needed to 
generate a position solution by triangulating. The site IDs give the FOVl reference 
points for coordinate transformations. 


18 



Table 3. FOVl Data Inputs 


FOVl Data Inputs 

Radar 

E, F, G, E', F', G', time, site ID, Q-bit, Track-bit 

Optics 

Azimuth, elevation, time, site ID, Q-bit, Track-bit 

Inertial Guidance System (IGS) 

X, Y, Z, X', Y', Z', time, site ID, Command receiver status 

GPS by Telemetry 

E, F, G, E', F', G', time 


The EFG means Earth Eixed Geodetie, whieh uses a Cartesian eoordinate 
system with its origin at the eenter of the earth. The axes are labeled E, E, and G and the 
veloeity eomponent in the direetion of those axes are labeled E', E', and G', respeetively. 
X, Y, Z are the axes of a Cartesian eoordinate system whose origin is established as the 
IGS position on the pad when the gyroseopes are uneaged (Thomas, 2008). 

EOVl ean be eonfigured to display a trajeetory determined by eombining 
all input sourees or a single souree. EOV1 also displays the variable flight azimuths and 
the predicted impact area. 

The Elight Termination System, also known as the Command Destruct 
system, is the means to carry out a decision to terminate a flight that violates the flight 
safety parameters. The system is a collection of ground based transmitters and antennas, 
a rocket borne receiver, and vehicle destruct package. The system is dynamic in that the 
different ground stations transmit their destruct functions based on the missile’s position. 
The active configuration of the command subsystem is controlled by an operator assisted 
by the Range Safety Control and Display (RASCAD) system, which considers the site’s 
health and status and the missile’s actual position along with the predicted trajectory. 
The health and the status of the vehicles command destruct receiver is monitored prior to 
liftoff (EO) when the vehicle begins using its internal batteries. At that time, a command 
signal is sent to the vehicle to saturate the receiver, so that it cannot receive an 
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uncontrolled signal that might be taken as a destruct eommand. In addition to the 
jamming signal, eheck tones are sent to trigger a response of health and status 
information from the receiver. 

The eommand system uses dedicated data links to eonneet Central 
Command, which is the control segment in the ROCC, to the launeh head eommand sites 
and the XY building. Cape lA and Cape IB are the launeh head sites that are conneeted 
with dedieated copper lines (Smith, 2008a). All other command sites are considered 
down range. These sites are Wallops Island, JDMTA, Argentia, and Antigua. Central 
Command uses dedicated secure copper lines to connect to the XY building where the 
eireuit is switched to the down range data link s . 

The entire eommand system ineludes links besides the ones that transmit 
the eommand functions. These include voice eommunieations and timing links as well as 
designated data for pointing antennas. For these purposes, the command sites are data 
consumers like other range sites. The dedieated links create a seeure eonnection to the 
launeh head command sites and to the XY building. The XY building is a 
communications network hub. From there a variety of links are available to the down 
range sites. The primary requirement is that there is no single point of failure, which is 
achieved by using two independent paths. This is usually a landline and a satellite 
connection, or in the case of JDMTA, a microwave radio link. The command functions 
are sent using the range’s High Density Data format whieh is transmitted at a rate of 2.4 
Kbps. 

The eommand system may someday use the common range network. The 
reasons that led to using a dedieated network need to be eonsidered in any plans to bring 
the command system on to the core network. The current requirement is to minimize risk 
(Smith, 2008a). If command were to use the eommon network, engineering would need 
to show that the risk remains very low. Different networking architectures and Quality of 
Serviee (QoS) provisions are available to ensure the delivery of command messages. In 
fact the right QoS settings would make the system better able to work if the network were 
under a denial of serviee type attack. The properly marked eommand messages would 
get through the malicious traffic. 
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4. 


Eastern Range Operational Configurations 


The typical range configuration varies depending on the launch vehicle and the 
direction of flight. One succinct source is found in the ER Instrumentation Handbook 
(Computer Sciences Raytheon, 2008) as a chart titled “Typical Instrumentation 
Configurations for Eastern Range Eaunch Vehicles and Elight Azimuths.” This guide is 
useful in determining which instrumentation sites are assembled to form the range 
configuration for a given operation. It is interesting to note the dependence on Wallops 
Island for its telemetry, radar and command assets for North Easterly launches. Wallops 
Island is not part of the Eastern Range baseline. To use the Wallops Island assets means 
connecting them to the ER with commercially leased communications lines. When 
choosing a configuration to model, one should also consider the use of mobile command 
and telemetry at down range sites. This thesis will model the range configuration used 
for a North Easterly launch, which includes Wallops Island as a supporting range, and a 
mobile command and telemetry system at Argentia. 

5. Communications Networking 

a. Publish/Subscribe Systems 

Publish/Subscribe (pub/sub) systems are a key technology for information 
dissemination. The basic functions of a pub/sub network are naturally publishing and 
subscribing. Publishing submits a piece of information, known as an event. The action 
of publishing an event is called a publishing operation. The event is generally structured 
as a set of attribute-value pairs, where the attribute has a name made up of a simple 
character string and a type. The type is one of the common primitive data types defined 
in programming or query languages. A subscription is the user expressing interest in data 
in terms of a set of constraints. These constraints are used to filter events. An event is 
said to match a subscription if it satisfies all the declared constraints. The verification of 
whether an event matches a subscription is called Matching. Subscription models are 
distinguished by the level of expressiveness they give to the subscriber’s interest. Highly 
expressive models lead to the possibility of a precise match. 
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Any module in a pub/sub communications system can take the role of 
Publisher or Subscriber. That is, the module can produce information (publish) or 
consume it (subscribe). System clients are not required to communicate directly with one 
another. The communications occur through systems nodes that coordinate themselves in 
order to route information from publisher to subscriber. Participant decoupling has 
advantages such as being able to ignore synchronization issues or direct addressing of 
subscribers. However, there are some disadvantages. It is very difficult to enforce any 
end-to-end QoS policy because of the non-deterministic behavior of the system. This 
non-determinism affects three fundamental aspects of QoS: security (specifically reliable 
message delivery), timely delivery, and trust relationship. A product discussed as being 
good is the Java Message Service (Corsaro, Querzoni, Scipioni, Tucci Piergiovanni, & 
Virgillito, 2006). It has the ability to handle a message-centric publish-subscribe model 
and it supports a point-to-point mode. 

Reliable delivery is affected by the various network hops involved in 
transmissions over asynchronous Wide Area Network channels or temporary node 
overloading. The probability of receipt is increased with event persistence (stored in 
memory) and with retransmitted events. 

Timeliness is a primary consideration. Real time applications often utilize 
a dedicated infrastructure for the strict controls they offer in order to meet timeliness 
requirements. Even in a completely managed environment the pub/sub system can have 
unpredictable processing delays at the nodes, or it can have routing anomalies. If 
timeliness needs to be closely controlled, the system should privilege point-to-point 
communications. This trades off the benefits of decoupling. Decoupling allows the 
infrastructure, rather than the publisher, to know all the subscribers. The benefit of that is 
the ability to scale the network to massive sizes with relative ease. 

Security and Trust considerations deal with both the need to access data 
and assurances that the event is not corrupted in route. 
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b. Data Distribution Service for Real-time Systems 

Many real-time applications require a pure data-centric exchange. 
Applications requiring selective information exchange are good candidates. Predictable 
distribution of data with little overhead is the primary goal. This can be controlled with 
Quality of Service parameters that affect predictability, overhead, and resource 
utilization. Distributed shared memory is a classic model, but it is difficult to implement 
efficiently over a network and it is not easily scalable (Object Management Group, 2007). 

D. SUMMARY 

Several stakeholders are involved in any discussion of the Spacelift Range 
architecture. The Eastern Range has a number of launch vehicles to accommodate, and 
they generally fly one of two basic trajectories (North East, or East). An interesting 
model is based on the most taxing load on the range network and will have as many 
different assets as practical, spread over a large geographic area. The point in time 
considered “the future” is the first major step in the range evolution that will be defined 
by the use of GPS metric tracking for all vehicles. GPS is currently used by some 
vehicles, and the range is equipped for this concept of operation. The lynchpin to 
operating the range system of systems is the data network. A viable networking option 
for the range is the Data-Centric Publish-Subscribe model, which is used in many real 
time applications. 
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III. ANALYSIS AND RESULTS 


A. INTRODUCTION 

The analysis presentation is organized to follow the seven-step methodology 
developed by Osmundson and Huynh (2005). 

B. ANALYSIS 

I. Development of System of Systems Scenarios and Operational 
Architectures 

The Eastern Range Capabilities Doeumentation (Computer Seienees Raytheon, 
2008) ineludes a chart titled “Typical Instrumentation Configurations for Eastern Range 
Eaunch Vehicles and Elight Azimuths” that specifies typical range configurations for a 
collection of vehicles and trajectories. Instrumentation assets are generally ranked Range 
Mandatory (meaning they are a “must-have”), Range Required (meaning a launch could 
proceed without the asset). Available Spare (to achieve reliability through redundancy), 
or User Required/Mandatory. User Required/Mandatory assets are not necessary for 
range safety. 

Command destruct sites at Cape Canaveral are generally considered launch 
mandatory. Command destruct sites at Jonathan Dickinson Missile Tracking Annex 
(JDMTA) are usually mandatory since there are times that the JDMTA sites have a better 
look angle. 

Telemetry at TEE IV (TAA-3c and TAA 50-3), located at KSC, is required for the 
Space Shuttle and mandatory for Delta and Atlas launches. JDMTA is required for East 
bound launches. The launches from CCAES or KSC generally require one of the four 
JDMTA telemetry assets. The other three are used for Navy Submarine Eaunched 
Ballistic Missiles. Space Shuttle launches add two more telemetry sites to the launch 
head area, one on Merritt Island and the other at Ponce De Eeon. 
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Optics are generally required for all range launehes. Many assets are mobile, so 
their loeation can be ehanged depending on the launeh eomplex used. 

Radar is eurrently required at CCAFS/KSC/PAFB. That usually ineludes several 
Missile Preeision Instrumentation Radars (MIPIR, whieh uses a parabolie reflector 
antenna) and a phased array Multiple Objeet Traeking Radar (MOTR). 

All eommand destruet sites are normally part of the range eonfiguration. Some 
discussions of the AFTS era envision it in full use around 2018. That may be a reason to 
keep the eommand sites on a separate sub-net, as they are now. They generally have very 
striet reliability requirements, whieh may be another reason to put them on a separate 
network. On the other hand, they have a redundaney requirement, and a no single-point- 
of-failure (SPOT) requirement. A data network that offers multiple routing possibilities 
may be a good eoneept to meet that need. The ORD (Headquarters Air Foree Spaee 
Command, DRSR, 2003) does not speeify redundaney directly, but does say in Seetion 
4.1.5.1 that “The ranges must be capable of uplinking commands (i.e. destruet, arm, safe, 
pilot tones/eheek ehannel 4 (WR), or control fuel burn) from launeh through powered 
flight or separation of the last stage designed to aceept eommands.” 

a. Conceptual Architectures 

The system of systems eoneepts being evaluated are likely points in the 
range evolution toward the LET plan for an Eastern Range that will eompletely use GPS 
metrie traeking by fiseal year 2011 (Shappell, 2008). A depletion of the EET plan is 
shown in Eigure 4. The strike-throughs indieate assets that are deemed no longer 
required when GPS metrie tracking is used for all vehieles. Divestiture of these assets 
will be phased, so the graphie makes a distinetion between “New Shutdowns” (Radars 
19.17 and 1.16 plus 3 mobile optieal traekers), and Previous “Shutdowns.” 
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LPLW8 = Launch Pad Lightning Warning System 
CGLSS = Cloud to Ground Lightning Surveillance Sys 
AMPS = Automated Meteorological Profiling Sys 
SODAR = Sonic Detection & Ranging s 

OSS = Ocean Surveillance Sys 
DRWP = Doppler Radar Wind Profiler 
MOTR= Multiple ObjectTracking Radar 


O = Previously ShutdoiWrt*^=l-JS*^ 


Figure 4. Conceptual View of Range Architecture (Slide 13, Shappell, 2008) 


The Eastern Range Capabilities Documentation chart titled “Typical 
Instrumentation Configurations for Eastern Range Eaunch Vehicles and Elight Azimuths” 
shows North Easterly launches using radars at Wallops Island and Argentia (Computer 
Sciences Raytheon, 2008). Given the current trend, this thesis assumes telemetry will be 
used instead. The radar 0.134 and the launch head optics will not be included in the 
range safety metric track. For the flight profile considered, the range configuration 
(conceptual architecture) shown in Figure 5 would likely be used. 



Figures. Conceptual Architecture 
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b. Operational Scenario 


The operational scenario considered in this thesis is a North Easterly 
Launch. The expectation is that North Easterly launches will make use of command and 
telemetry at Wallops Island and will add mobile command and telemetry assets at 
Argentia. JDMTA typically supports North Easterly launches with two telemetry 
antennas and command. Currently the only ER GPS processing equipment, the 
Translated GPS Receiver System (TGRS) is located at JDMTA. The range allows 
customers to monitor data during the launch and access recorded data after the launch. 
There are currently no provisions for customers to attach their own instrumentation, such 
as telemetry antennas, or optics to the network as either an input source or a consumer of 
designates data. 

Any operation will use voice and video to monitor status and for command 
and control. The Weather and Area Surveillance subsystems will also contribute to the 
network traffic. These loads are considered as a steady state level of background traffic. 
This thesis considers Area Surveillance to be a command and control function that 
primarily uses voice and video. Weather is currently connected to the range with a single 
OC-3 connection. Eor the purposes of this thesis, it is assumed that the required 
bandwidth is 75% of the available OC-3 capacity (Note: each OC-3 is capable of carrying 
155 Mbps; 75% equals 116 Mbps). Similarly, it is assumed that video consumes 75% of 
the available bandwidth from the five OC-3 lines connecting “TVOC” to the core 
network (NOTE: five OC-3 lines are capable of 775 Mbps; 75% equals 581 Mbps). 
Voice is generally given 32 Kbps circuits, as seen in the CSR Technical Training 
Orientation (Gillis, 2008). Using the ERAT estimate of 600 voice users (ERAT, 2008, 
slide 111), each using 32Kbps circuits, requires 19.2 Mbps. This would be the case were 
it not for the ability to multiplex the voice circuits. One T-1 line, moving Extended 
Superframes at 1.544 Mbps, can handle 576 phone calls (Gillis, 2008). Going from 576 
to 600 by linear scaling means 1.608 Mbps are used for voice. 
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In the modeling of the proposed modernized network, the voice and video 
are considered to be a constant steady-state level that shares the same communication 
infrastructure used by the sensors. The level of activity is that assumed by the FRAT. 
The FRAT network engineers (Gorlick, 2008), assuming the use of voice compression 
software, estimate each user will require 16 Kbps, which results in a 9.6 Mbps 
requirement for 600 users. For the video use of bandwidth, the assumption is that there 
will be 150 live feed cameras producing 1280 x 1024 pixel images (i.e., high definition 
TV quality) at a rate of 30 frames per second using real-time compression. The resulting 
load is less than 1 Gbps, (FRAT, 2007, slide 107), so the video load is assumed to be 999 
Mbps. The FRAT does not explicitly consider the network loading imposed by the 
Weather and Area Surveillance subsystems. Again, weather is considered to use 75% of 
the bandwidth available from the single OC-3 connection and Area Surveillance is part of 
the voice and video load. 

c. Range Network 

In this thesis, the range is viewed as a sensor network with a hub and 
spokes out to the remote sensors. The hub includes the core data network. Centralized 
Telemetry Processing System (CTPS), FOVl and the command destruct control system 
(Figure 6). The core data network receives a lot of attention in the FRAT plan (FRAT, 
2007), since this part of the network needs to reliably meet strict timeliness requirements. 



Figure 6. Hub and Spoke Sensor Network 
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d. Alternative 1: Legacy Network Model Architecture 

A review of the Eastern Range Capabilities Doeumentation ehart, “Typieal 
Instrumentation Configurations for Eastern Range Eauneh Vehicles and Elight 
Azimuths,” shows that Wallops Island, JDMTA and the Eauneh Head assets will all be 
tracking at the same time. The times the missile is visible from JDMTA, the Eauneh 
Head, Wallops Island, and Argentia are shown in Table 4 (Computer Sciences Raytheon, 
2008). The network model in this thesis considers data loads from Wallops Island, 
JDMTA and the Eauneh Head assets simultaneously. JDMTA and the Eauneh Head will 
have dropped off by the time Argentia can track the missile. 


Table 4. Time Span (in seconds) of Missile Visibility from Various Sights 



JDMTA 

Launch Head 

Wallops Island 

Argentia 

Delta II 

24-466 

0-482 

217-617 

504-890 

Atlas V 

Not listed 

0-483 

217-617 

549-793 

Shuttle 

49-450 

0-425 

196-683 

Not listed 


This model architecture uses the command destruct system and the sensors 
left by the EET plan after the range begins using GPS metric tracking for all launch 
vehicles. The metric tracking data, both GPS and IGS, will come through the telemetry 
systems. This configuration removes the radars and the optics from the range safety 
solution, so there will be no data flow from them, but they will receive designate data 
from EOVl. The communications infrastructure will be the equipment currently in use. 
Early in the launch, the assets contributing to the range safety solution are included 
among those seen in Eigure 7. The model is based on these assets. The focus is the 
capability of the network to meet the bandwidth demands and meet the timeliness 
requirements. 
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e. Alternative 2: Modernized Network Model Architecture 

This model architecture uses the same range systems as alternative 1, but 
the data network will use IP data packets rather than the current ATM cells. 

2. Identification of System Threads 

This thesis, following a thread from the OV-5 (Space Lift Range System 
Contractor, 2007a) focuses on the range’s ability to conduct launch operations. Thread 3, 
“Execute launch and test range operations,” has one top-level guard condition for 
reacting to a non-nominal flight when the missile violates fight safety parameters. It 
would involve a decision as to whether or not to destroy the rocket or otherwise interrupt 
powered flight. 

The “Launch and Test Range Operations” thread is decomposed into: 

3.1. Monitoring heath and status of range instrumentation 

3.2. Monitor space and launch vehicle preparation 

3.3. Determine launch Go/No-Go status 

3.4. Manage real-time flight operations 

3.5. Track objects 

3.6. Perform post launch activities 
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Thread 3.4, “Manage real-time flight operations,” eovers the eontingeney for non- 
nominal flights that ealls for sending a flight termination funetion. 

As for the end of the thread, eonsideration is given to how OV-5 deeomposes 
Item 3.4, “Manage real-time flight operations,” shown below. Items after 3.4.4.1 are 
shown in italies. The timeliness requirement will ehange eonsiderably after all the debris 
traeking is eomplete. For that reason. Item 3.4.4.1 will be the end point of the thread. 

3.4.1. Monitor best souree metrie data 

3.4.1.1. Reeeive and send raw telemetry data 

3.4.1.2. Reeeive and send radar metrie data 

3.4.1.3. Distribute time eritieal range safety telemetry information 

3.4.1.4. Reeeive best souree metrie data 

3.4.1.5. Monitor and seleet sourees to ensure aeeurate display of metrie 
and diserete indieators 

3.4.1.6. Seleet and transmit best souree metrie data 

3.4.1.7. Reeeive best souree designate/aequisition data 

3.4.2. Confirm Vehiele performanee with respeet to predieted vehiele 
performanee 

3.4.2.1. Deteet missile liftoff 

3.4.2.2. Reeeive missile liftoff indieation 

3.4.2.3. Report visual vehiele in-flight behavior 

3.4.2.4. Evaluate vehiele in-flight telemetry measurements 

3.4.2.5. Control mission flight eontrol display 

3.4.2.6. Monitor airborne range safety system health and status 

3.4.2.7. Monitor vehiele performanee with respeet to predieted 
performanee 

3.4.3. Terminate non-nominal vehiele flight 

3.4.3.1. Deeide to terminate non-nominal flight with respeet to violations 
of mission rule eriteria 
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3.4.3.2. Declare vehicle flight non-nominal 
3.4.3.3 Send flight termination function 

3.4.3.4. Send back-up flight Termination Functions 

3.4.3.5. Transmit termination functions 

3.4.3.6. Verify vehicle destruction 

3.4.4. Perform debris and toxin dispersion analysis based on catastrophic abort 

3.4.4.1. Determine debris impact area 

3.4.4.2. Generatepost-destruct data 
3.4.43 Receive and report post destruct data 

3.4.4.4. Determine refined instantaneous impact point data and debris 
impact area 

3.4.4.5. Determine updated toxin release times based on catastrophic 
abort 

3.4.4.6. Receive and report updated toxin release times 

3.4.4.7. Monitor updated toxin release times 

3.4.4.8. Release assets when clearance toxic times expire 

3.4.5. Perform mission data lock down 

3.4.5.1. Ensure all launch related records and data is secured 

3.4.5.2. Direct data control and disposition actions 

3.4.5.3. Conduct data collection and disposition actions 

3.4.5.4. Gather, preserve and protect evidence 

3. Representation of Operational Architectures in a Unified Modeling 
Language (UML)-Like Format 

This step corresponds to the OV-6c Diagram of the Department of Defense 
Architecture Framework (DoDAF). It provides an examination of the time-ordered 
exchange of information between the scenario actors. This view (Figure 9) helps define 
the interactions making up the operational thread and can help ensure each actor has the 
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necessary information when it is needed to perform the assigned operational activities. 
The range uses a hybrid view called an OV-6x. This analysis will draw excerpts from the 
OV-6x for non-nominal flights. The timing requirements in this view are driven by range 
safety considerations. 

The Missile Flight Control Officer (MFCO) monitors the missile’s flight to 
determine whether it is violating flight safety rules. The OV-6 will focus on the MFCO 
who is stationed in the ROCC. The MFCO is part of a team that includes the Range 
Control Officer, and Flight Safety Officer, as well as assistants to monitor the command 
destruct system and control displays. For this OV-6, this team will be considered a single 
entity referred to as the MFCO. The basic information flow is from the remote sites to 
FOVl, where it is processed and displayed in a form useful to the MFCO. FOVl also 
sends target acquisition data (designate data) to the remote sites. The MFCO initiates the 
destruction sequence if deemed necessary. 

The telemetry stream carries both GPS and Inertial Guidance System (IGS) metric 
tracking data. IGS data is transmitted to the ROCC where it is processed through CTPS. 
CTPS separates the data and outputs X, Y, Z, X', Y', Z', time, and site ID to FOVl. 
CTPS also processes the vehicle health and status information for display to the MFCO. 
GPS metric tracking data processing is done on the ground at the JDMTA telemetry site 
by a system called the Translated GPS Receiver System (TGRS). TGRS determines the 
missiles state vector and sends it to FOVl. 

Optics and radar are still actors in the launch scenario even though their data will 
not be used to determine the missile state vector. Optics will supply visual data to the 
ROCC throughout the operation. Optics and radar will both track debris and they will 
both receive designate data from FOVl. 

The event sequence (Figure 8) does not change as the missile flies down range, 
but the timeliness requirements do. For the launch area, the timing is 400 milliseconds 
for a sensor to get the data frame to FOVl, and then FOVl has 100 milliseconds to 
process the data and produce a display. The MFCO needs to interpret the display, 
determine that a vehicle needs to be destroyed and then initiate the destruct sequence. 
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The time allotted to the MFCO is 1500 milliseeonds. The eommand destruet system then 
has 55 milliseconds from the time the destruet sequence is initiated to the time the 
leading edge of the pulse carrying the command function leaves the antenna. For down 
range sites, the sensors have 1500 milliseconds to get a data frame to FOVl, and the 
command system has 55 milliseconds plus the data link latency which varies depending 
on the specific site (Smith, 2008b) to start sending the destruet signal. 
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Figure 8. Non-nominal Launch Event Timing 


35 















Figure 9. Representation of Operational Scenario 
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Representation of Operational Seenario (eontinued) 
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Representation of Operational Seenario (eontinued) 
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Representation of Operational Seenario (eontinued) 
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4. Identification of System of Systems Design Parameters and Factor 

Levels 

Network system performanee is driven by the way the various range systems are 
joined to ereate the system of systems. A popular approaeh is the use of 
Publish/Subseribe Middleware. Quality of Serviee measures that lend themselves to 
beeoming design parameters for this analysis are 1) timeliness 2) reliability and 3) 
availability (Corsaro, Querzoni, Seipioni, Tueei Piergiovanni, & Virgillito, 2006). For 
this applieation, availability addresses sizing the network to ensure data ean flow to the 
required loeation by the time it is needed. The availability parameter is evaluated using a 
throughput analysis and does not eonsider availability in the sense of equipment failure. 

a. Timeliness 

The prineipal driver for sensor data timeliness is the FOVl 
synehronization seheme that groups 400-milliseoond old data frames. This is one 
element in an overall range timeliness requirement. The overall range timeliness 
requirement is driven by the need to proteet the publie from the hazards potentially 
resulting from a missile that violates flight safety rules. 

b. Reliability 

In the legaey network eonfiguration, reliability is addressed by requiring 
two independent paths for range safety eritieal data for reliably through redundaney. For 
the parts of the range network that eonsist of leased eommereial lines, the reliability 
guaranties need to be eonsidered beeause how the reliability is aehieved is beyond the 
range’s eontrol. Deeisions to migrate to a new range network eonfiguration will need to 
eonsider network reliability and examine the fault toleranee and robustness of the 
network. Simply mandating two paths may not be the best solution. Other network 
topologies with the ability to route traffie to meet the QoS requirements might prove to 
be the best solution. Corsaro et al (2006) suggest that faetors affeeting reliability inelude 
persistenee of events and event retransmission. In eonsidering a move toward an IP- 
based network, one might eonsider if there is time or a need to resend lost paekets. This 
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may not be necessary since data packets are set every 100 milliseconds. Additionally, 
FOV1 is tolerant of an occasional missed data frame. This, combined with data latency 
limitation, makes retransmission unnecessary. 

Corsaro et al (2006) also discuss a “lifespan” parameter that allows control 
over the time interval for which the data will be valid. The lifespan of the data is set by 
FOVl. Radar and optics data frames up to one second old will be processed whereas 
telemetry borne data (IGS and GPS) up to 1.2 seconds is allowable, although a 400- 
millisecond time span for all data is desirable. The current FOVl configuration is set up 
to synchronize inputs so that all 400 millisecond old data frames are processed at the 
same time. If the data is not used in that time, it should not remain in the network. 
Additionally, there is no reason to check receipt of a data frame and communicate it back 
to the provider, because messages are created and sent rapidly (10 per second). If an 
expected data frame fails to arrive on time, FOVl will compute the solution using 
available data. 


c. Availability 

Ensuring data arrives where it is needed in the allotted time is dependent 
on having enough bandwidth. There are two basic types of data used during launch 
operations: range safety data and customer data. The range safety data is necessary to 
determine a state vector for the missile and for monitoring health and status of the 
command receiver. The customer data can be subdivided into two groups: the data that 
need be processed in real time and the data that can be recorded and processed after the 
mission. Basic vehicle health and status data is sent real time. There is a dividing line 
between the data that can wait based on customer wants. In some cases, the entire 
telemetry stream needs to be sent to the ROCC, since the safety data may not be put on a 
dedicated channel. 

Ideally, one would not have to wait for data, but certain data, such as 
engineering analysis optics data, would require huge amounts of bandwidth. Since 
analysis can be done after the launch, the data can be stored and transmitted later. Radar 
imaging or tracks made with very high sample rates could potentially create large 
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amounts of data that could be used for later analysis of debris metries and diserimination. 
Clearly some data needs extensive analysis that eannot be done in the time span of a 
launeh operation, so transporting it ean happen after the operation. 

With a view of the range as a sensor network, the throughput requirements 
for the legaey sensors are very small. Radar and opties are designed for a 2.4-Kbps data 
stream, and Telemetry is set up for a 4.8-Kbps data steam. These rates are aetually a 
bigger problem for timeliness than for throughput, beeause it takes a signilieant amount 
of time to build a data frame. A 240-bit frame built at 2.4-Kbps and 4.8-Kbps rates takes, 
respeetively 100 and 50 milliseeonds to eomplete. Additionally, there is a 60 milliseeond 
delay when transporting these sub-rate data frames onto the range network (Gillis, 2008). 

The telemetry eapaeity requirement needs to be evaluated as new Spaeelift 
vehieles are developed. The Telemetry Subsystem Speeifieation is ealling for 10 Mbps. 
Early indieations are that the NASA Aries program will have telemetry streams as large 
as 30 Mbps. One approaeh to handling this load is for the telemetry stream to have a 
spare ehannel to allow a small portion of the stream to be separated for use for range 
safety data, and the rest reeorded. Another approaeh may be to have an IP-based 
telemetry signal that the site proeesses at the routing level (Gorliek, 2008). 

5. Transformation of UML-like Format Representation into Executable 

Models 

The design parameters eonsist of availability (throughput) and timeliness. 

a. Availability 

The availability model analyzes required data flow by foeusing on the 
nodes eonneeting remote site data links to the eore data network. The model sums the 
volume of data that flows in and out of the eore network through various nodes and 
eompares the result to the rated eapaeity of 622 Mbps. Similarly, the individual 
throughputs are summed and eompared to the node throughput eapaeity of 2088 Mbps. 
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The core has eight switches on the outer ring and seven on the inner ring. 
This analysis models the core as six switches with four on the outer ring and two on the 
inner ring (Figure 10). The primary focus is on the range safety information and the need 
to process it at the ROCC and present it for consideration to the MFCO. In addition to 
the flow of range safety data to FOVl, and the target acquisition data going back to the 
remote sites, the analysis assumes steady state network traffic that includes video, voice, 
and weather. 



Figure 10. Model Representation of Range Network 


With a focus on getting sensor information to FOVl/DRSD, the paths 
being modeled are 1) Telemetry data to get on the core for transport to CTPS, then to 
FOVl, and 2) Telemetry data to get on the core for transport to TORS, then to FOVl 
(Figure 11). 
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State \'ector. Health and Status 

-► 

,Designate Data 


Remote site Core TGRS ROCC FO\'l DRSD 


State \'ector^ 

^Designate Data 
Figure 11. Basic Data Flow Model 

During a launch operation, the circuits, or data paths, are predetermined. 
The only variation comes from routing on the core. The core rings are designed to be 
fault tolerant in that they react to a node failure by routing the network traffic around the 
ring in the opposite direction. The only capability lost is the ability to add or remove data 
from the core via the failed node. The input and output nodes for the circuits stay static. 
The reliability issue is addressed by setting up redundant paths that carry the same data. 
The basic node-by-node analysis of throughput is done for the current network and for 
the FRAT proposed network that is based on IP packets. The current network uses ATM 
cells. The type of data flowing on the network will be the same, but the volume will 
differ slightly. The node model used is shown as Figure 12. 
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Figure 12. Basic Flow Model 


The sum of the inputs and outputs is compared to the capacity of the data 
link connecting to the node to determine if the link has the required bandwidth. 

b. Timeliness 

The timeliness model analyzes the latency of the data flow from remote 
sensors to FOVl. The focus is on the network— both the legacy and FRAT proposed 
network. The analysis is done by summing the data latency caused by the various 
processes performed to create the data links. The data link latency is added to the TGRS 
or CTPS processing time and compared to the 400 millisecond allocated for getting data 
to FOVl. The CTPS processing time is assumed to be the difference in the time budgets 
for telemetry and radar, which is an extra 200 milliseconds. The TGRS processing time 
is assumed to be the same as CTPSs. 

The difference in data latencies is most pronounced at the edge devices 
that transition data on or off the core network. The data latency in the legacy network 
caused by the edge devices is tabulated in Table 5 (Morton, 2008). 


Table 5. 
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Table 6. Edge Deviee Delay Times from Interfacing with Various Circuit Types 


OC-48 transitioned to/from 

Delay 

(milliseconds) 

Low speed synchronous serial (2.4 Kbps) 

60 

Individual DSO (56 Kbps) channel in DS-1 

37 

DS-1 circuit 

3 


An IP packet-based network will also introduce a data latency at the edge 
devices. The latency is estimated to be 5-10 milliseconds (Bryant, 2008). Since the 
legacy network meets the latency requirements and since the proposed IP network is 
faster, the IP network will meet the need. 

Review of the data link latency of a range configured to use GPS metric 
tracking for range safety now follows. The timeliness analysis focuses on the circuit path 
that is the worst case in terms of time budgets. The tightest time requirement is for the 
launch head sensors. They have to have data to FOVl in no more than 400 milliseconds. 
TEL IV (telemetry) will be the only launch head sensors left after the range begins using 
GPS metric tracking for all launches. The analysis focuses on the data links that take 
TEL IV (launch head) data to JDMTA (down range) to be processed through TGRS and 
then carries the TGRS computed state vector to FOVl. 

TEL IV data is routed through the XY building as it is transmitted to 
JDMTA. The time needed to get data from TEL IV to the XY building is 5 milliseconds. 
This value is based on a measured time of 10 milliseconds for telemetry data to pass from 
the TEL IV WANIU through the CTPS WANIU (Space Lift Range System Contractor, 
2004). Because the latency for traveling along the fiber optic data link is negligible, this 
analysis assumes a 10-millisecond latency is attributable to processing by two WANIUs, 
each taking 5 milliseconds. This assumption is used for both the microwave path and the 
landline path. Data also has both a microwave path and a landline path from the XY 
building to JDMTA. 
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The landline trip from the XY building to JDMTA begins at switch 
XY_RNE_U15 and travels via commercially leased lines consisting of a 56-KB 
multiplexed data lines, four T-1 lines, and two 64-KB control lines (Computer Sciences 
Raytheon, 2008). The data latency of the leased lines is estimated because the exact 
routing is not known. To estimate the data latency, this analysis assumes the data is 
aggregated on to an OC-48 line for a section of the trip, but the section is too short to 
realize any advantage over using the T-1 lines. The result is added latency for the 
conversion process. Additionally, the analysis assumes that the path length is twice the 
shortest route distance. The trip from switch XY_RNE_U126 to JDMTA and back will 
be modeled as shown in Eigure 13. 

LcMcdLandlln* Trip to JDMTA 



Eigure 13. Eandline Path Model 


Analyzing the microwave path begins with the assumption that the data 
that travels from TEE IV via microwave to the XY building will stay on the microwave 
path and will be relayed to JDMTA. The alternative is to put the TEE IV data onto the 
core through the OC-48 fiber from switches XY RNE UI13 to XY_RNE_UI26. Doing 
so would involve processing the data through the SONET multiplexer to put the data on 
the core, and back through another SONET multiplexer to get back on the microwave 
link. 

The microwave path from TEE IV to JDMTA goes through 5 repeater 
stations and travel 118.2 miles. When the data gets to JDMTA it goes through a WANIU 
before it is processed by TORS. On the return trip, the TORS output data is multiplexed 
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and aggregated into a 5 3-Byte data frame that can be put onto the network, which will 
take approximately 25 milliseconds. Figure 14 illustrates this path. The processing time 
used in this analysis for multiplexing and de-multiplexing is derived from latency 
measurements for telemetry data coming from the remote sites. The measurements were 
reported in a characterization of the Post-Detect Telemetry Subsystem WANIU (Space 
Lift Range System Contractor, 2004). The measurement is taken from the time data 
entered the WANIU at the remote site until it is processed through the WANIU that feeds 
into CTPS. To determine the time attributable to multiplexing and de-multiplexing, the 
portion of that time attributable to data traveling the physical distance from remote site to 
the ROCC is subtracted from the measured time. The resulting time is divided by two 
since there is a WANIU at both ends. After the return trip via the microwave system, the 
data goes through another Alcatel radio and is multiplexed in order to input into switch 
XY_RNE_126. 

Microwave path 



Figure 14. Microwave Path Model 


The delay from converting the data to an analog radio transmission is 
assumed to be the same as the repeater time delay since both operations are processed 
through an Alcatel 4308S radio. Some insight into the time delay comes from a study 
(Allen, 1994) that characterizes the delay in the repeaters used in an Alcatel Network 
Systems microwave network. The study reports the worst-case delay of 577 
microseconds. 
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The time required for TGRS data to reach the core is the same as the time 
necessary to reach FOVl because the core is so fast that the latency from the XY building 
to FOVl is negligible (Morton, 2008). Therefore, the total latency for getting a GPS state 
vector from telemetry data collected at TEL IV data is the sum of the time needed to get 
telemetry data from TEL IV to the XY building, the time to get the data to JDMTA and 
back, and the TGRS processing time. 

c. Timelines: Backward Compatibility 

The effect of making modern sensors adhere to the legacy 
communications standards is evaluated by considering the range radar re-capitalization 
projects. Legacy radar produces data in 240-bit frames. The re-capitalized radars using 
MIT-LL ROSA are required to produce such data, however the 240-bit data frame is not 
amenable to transport on the data network, which transfers T-1 size data frames. The 
process time for converting 240-bit data frames to T-1 frames is 60 milliseconds 
(Computer Sciences Raytheon, 2008). In addition to the 60-millisecond conversion 
latency, there is an additional 100 milliseconds needed to receive the 240 bit data frame 
at the 2.4-Kbps rate resulting in 160 milliseconds for the conversion process. This 
latency and the system complexity that come with this conversion could have been 
avoided because the ROSA data is readily available in the T-1 format. The requirement 
for the new radars to output a legacy format should be changed so the output is 
compatible with the data network. 

6. Application of Design of Experiments 

This thesis compares two architectures rather than comparing a variety of 
solutions that were generated by varying several parameters. This course of action was 
shaped by a Headquarters Air Lorce Space Command (AFSPC) decision regarding the 
evolution of the range. This thesis is concerned with evaluating the range readiness to 
achieve the AFSPC commander’s vision and considers the feasibility of adopting the 
FRAT. The problem is bounded by considering only the minimum and maximum data 
load on the range network. The minimum load is associated with the currently network 


49 



and the maximum load would correspond to the FRAT plan network. Design of 
experiments is not used since only two configurations are considered. 

7. Modeling and Analysis of Results 

Two models are used, one to assess availability and the other to evaluate 
timeliness. The availability model analyzes required data flow by summing the volume 
of data that flows in and out of the core network through various nodes and compares the 
result to the rated capacity of 622 Mbps. Similarly, the individual throughputs are 
summed and compared to the node throughput capacity of 2088 Mbps. The timeliness 
model analyzes the latency of the data flow from remote sensors to FOVl. The focus is 
on the network— both the legacy and FRAT proposed network. The analysis is done by 
summing the data latency caused by the various processes performed to create the data 
links. 

A large set of the data that flows through the network is modeled as steady-state 
network traffic, consisting of video, voice, and weather data. Additional throughput 
includes 20 Mbps of telemetry data (10 Mbps on both the primary and secondary paths) 
from each of three sites, two sets of TGRS data, and two sets of designated data returning 
to the remote sites. The node throughput analysis is summarized in Table 6. 
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Table 7. Network Traffie that Passes Through the Network Nodes 



Uegacy Network (Mbps) 

FRAT IP Based Network (Mbps) 

Video 

581 

999 

Voice 

1.608 

9.6 

Weather 

116 

116 

Telemetry 

60 

60 

TGRS 

0.074 

0.082 

Target Acquisition Data 

0.008 

0.010 

SUM 

758.7 

1184.6 

Capacity 

2088 

2088 

% Used 

36 

57 


One major differenee between the legaey network and the FRAT proposed 
network is that the FRAT plan ealls for using high definition quality video and voiee over 
IP. Another differenee is that the legaey network uses 53-Byte eells eompared to the 64- 
Byte IP paekets. This differenee will have a small impaet on the bandwidth eonsumed by 
the legaey data. In order to reduee lateney, low rate data frames are put in eells (or 
paekets) that are sent before they are full, beeause it takes too long to fill the eells with 
the low rate input. In the eurrent range network, 424-bit eells are sent with the legaey 
240-bit frame and 184 filler bits, whieh use 1.77 times more bandwidth than eells 
eompletely filled with data. Similarly, a 64-Byte paeket eonsumes 2.13 times more 
bandwidth. This bandwidth penalty is applied to the legaey data eoming from TGRS and 
CTPS, as well as the Health/Status data and the designated data. A eomparison of the 
bandwidth eonsumed under different data strueturing options is summarized in Table 7. 
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Table 8. Comparison of Bandwidth Consumed Under Different Data Structures 



Raw Data (Mbps) 

Data in Cells (Mbps) 

Data in IP Packets 

(Mbps) 

TGRS 

0.019 

0.034 

0.041 

CTPS 

0.014 

0.025 

0.029 

Health/Status 

0.064 

0.113 

0.136 


Note that the terms input and output are from the point of view of the core. When 
a process needs data, it is an output from the core. The results from running the process 
are inputs to the core. For example, processing TRGS at JDMTA requires that the TEL 
IV and Wallops telemetry streams be taken as output from the network core. JDMTA 
will process data with TORS and input the data on to the core. JDMTA will also input its 
own telemetry stream so it can be processed at TEL IV and by CTPS. 

a. Availability 

The nodes that bring Telemetry data to CTPS are the ATM switches 
designated as ROCC GNE UllO, which handles CTPS A, and ROCC RNE Ul 11, 
which handles CTPS B. The throughput model for ROCC GNE Ul 10 is shown in 
Eigure 15 below. The results for all the nodes are summarized in Table 8. 
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Core Node for CTPS 
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Figure 15. Core Node Conneeted to CTPS 


Another important set of nodes for range safety are the nodes that send 
Telemetry data to JDMTA where it is proeessed through TORS. JDMTA is eonneeted to 
the XY building by eommereial eommunieation links and by an Aleatel microwave radio 
system. The microwave link has the capacity of an OC-3 line and the commercial link 
uses four T-1 lines (Space Lift Range System Contractor, 2007). All JDMTA data comes 
through a single Cellworx® switch designated as XY_RNE_U126. The range generally 
uses redundant data links but this switch is a single point of failure because both links use 
the switch. If this single point of failure is a problem, a potential solution is to switch 
microwave receiver connections between JDMTA and TEL IV, which is connected to 
switch XY_RNE_U113, also in the XY building. 
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The connection between the core and JDMTA needs further consideration. 
The commercial link, using four T-1 lines, is only capable of carrying 6.176 Mbps. If 
entire telemetry streams do need to be sent for TGRS processing, the requirement would 
be 40 Mbps. Either the volume of telemetry data needs to be reduced or the link capacity 
increased. 

After the data is processed through CPTS and TGRS, it needs to be 
processed by FOVl and DRSD and displayed for the MFCO. FOVl B and DRSD can 
receive inputs through switches ROCC_RNE U102 and ROCC_RNE_U 111. FOVl A 
receives its data from ROCC GNE FllOlandROCC RNE FlllO. 


Table 9. Network Traffic Put On or Removed from the Core Through Various Nodes 
(Note that the capacity to add and remove data is 622 Mbps) 



Legacy 

FRAT IP Based 

Total 

% Used 

Total 

% Used 

ROCC_GNE_U110 

40.32 

6.5 

40.38 

6.5 

ROCC_RNE_Ulll 

40.32 

6.5 

40.38 

6.5 

XY_RNE_126 

80.07 

12.9 

80.07 

12.9 

XY_RNE_113 

40.07 

6.4 

40.09 

6.4 

ROCC_GNE_U101 

0.238 

0 

0.262 

0 

ROCC_RNE_U102 

0.238 

0 

0.262 

0 


b. Timeliness 

The commercial landline model sums the time required for each leg of the 
path from the XY building until the TGRS data is put on the core through switch 
XY_RNE_U126. The results are shown in Figure 16. 
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Leased Landline Trip to JDMTA 
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Delay (msec) 

Convert to T-1 
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Travel 118.2 miles 

0.63 

Convert to OC-48 

3 

Convert to T-1 

3 

Travel 118.2 miles 

0.63 

Convert to OC-48 

3 

Total 

45.22 


Figure 16. Data Timeliness Model Using Commereial Landlines from JDMTA to the 

Core Network 


The total data latency is determined by adding the latency for data travel 
from TEL IV to the core, the TORS processing time, and the time needed to get data to 
JDMTA and back. The result is an overall time of 250 milliseconds, which is within the 
400-millisecond time budget. 

The microwave link model sums the time required for each leg of the path 
from the XY building until the TORS data is put on the core through switch 
XY_RNE_U126. The results are shown in Eigure 17. 
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Figure 17. Data Timeliness Model Using the Mierowave Radio System from JDMTA 

to the Core Network 


The total data lateney is determined to be 267 milliseeonds, whieh 
aeeounts for traveling from TEL IV to the eore network, the TGRS proeessing time, and 
the time needed for data to travel to JDMTA and baek. This lateney is within the 400- 
milliseeond time budget. 

C. RESULTS 

Regarding the availability requirements, the total load on the data network is 
estimated to be 36% of the eapaeity using the legaey systems and 57% if various 
modernized systems (e.g. voiee over IP, IP based video) are used. Range safety data is 
less than 8% of the total load. As for the ability to add and remove data from the eore, 
range safety uses at most 13% of the available eapaeity, whieh is driven by large volumes 
of telemetry data. 
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The commercial leased lines to JDMTA are a potential area for a data bottleneck. 
The data link, using four T-1 lines, is capable of carrying 6.176 Mbps. The capacity 
required to send all the telemetry data is 40 Mbps. The problem of the bandwidth 
demand exceeding the available capacity can be addressed by either increasing capacity, 
or decreasing demand. The demand can be decreased if the portion of the telemetry 
stream carrying the GPS data can be separated so that only a subset of the data is sent to 
JDMTA. If the GPS data were carried on a separate telemetry channel, the required 
capacity would likely be close to 40 Kbps. 

With regard to timeliness, sending telemetry data from TEL IV down range to 
JDMTA so it can be processed through TGRS is the most challenging because TEL IV 
must meet the timeliness requirements of a launch head sensor. The data latency of the 
GPS state vectors received by TEL IV is estimated to be 250 milliseconds for the landline 
data link and 267 milliseconds using the microwave system. The launch head timeliness 
requirement of 400 milliseconds is thus met. 

The backward compatibility requirement needs to be viewed from a network 
perspective. Interfaces are currently defined by the legacy serial data format rather than 
by the actual communications network. Addressing these legacy interface requirements 
was done at the project level by the radar team, rather than with a re-look at the range 
system, resulting in an extra 260 milliseconds of data latency. With the growing 
dependence on telemetry, and the importance of data timeliness, the interfaces need to be 
considered carefully. 

D. SUMMARY 

This thesis takes the range as a weapon system point-of-view and focuses on data 
availability and timeliness to meet the range safety requirements, which are derived from 
the basic need to protect the public and range personnel. The range is also required to 
perform many Automated Information Systems functions which demand far more 
bandwidth than the range safety functions, whose timeliness is less critical. 
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From a network perspective there is ample bandwidth to meet the range 
requirements. Moving to an IPv6 based network will not have a significant impact on the 
available bandwidth, assuming the existing cables and fibers are used. The most 
significant bandwidth limitation is the commercially leased data link from the core to 
JDMTA. The link cannot carry the entire stream of telemetry data, so the portion 
carrying the GPS data needs to be separated. After the change to using GPS for all 
vehicles, data timeliness requirements can be met with the current network or an IPv6 
based network. Data timeliness needs to be considered carefully in so far as it is affected 
by the location of the TGRS. Additionally, there exists the potential to improve 
timeliness by examining the need to maintain legacy communication standards. 
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IV. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

Answering research question 1 (Question 1: Should the Spacelift Ranges migrate 
their data networks to an IPv6 standard as proposed by the Future Range Architecture 
Team?): Both the current range network and an IPv6 based network would satisfy the 
data availability and timeliness requirements for range safety after the change to using 
GPS metric tracking for all vehicles. 

From an availability point of view, range safety data is less than 8% of the 
network data load. The factors treated as steady-state background traffic place a much 
greater demand on the data network capacity. This background traffic is estimated to be 
36% of the available network capacity using the legacy systems and 57% if various 
modernized systems (e.g., voice over IP, IP based video) are used. As for capacity to add 
and remove data from the core, range safety uses at most 13% of the available capacity, 
which is driven by large volumes of telemetry data. Again there is ample bandwidth 
available for systems like voice over IP and IP based video. 

There are reasons beyond meeting the range safety requirements that make the 
migration to an IPv6 standard a reasonable course of action. The network is important to 
interoperability and the ease with which modernized sensors can be accepted on to the 
range. With the wide acceptance of the IP packetized data, it is likely that modernized 
components would favor the IP standard. The ROSA radar, voice over IP, and IP based 
video are examples. Additionally, compliance with DoD Joint Technical Architecture 
calls for using IPv6 (FRAT, 2007). Besides the interoperability requirements, there is a 
need to address the sustainability of the legacy network, which is considered to be 
unsupportable (Laird, 2008). 

Answering research question 2 (Question 2: In modernizing the range data 
network, is it more advantageous to make legacy components forward compatible or to 
make modern components backward compatible?): Currently, the range uses both 
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approaches suggested in question 2. Legacy components employ middleware for use 
with the relatively new data network and modem components are backward compatible 
to legaey data formats (e.g., ROSA radars). Since eurrent praetices have demonstrated 
the feasibility of making legacy sensors forward eompatible, the range should move 
toward a strategy of making modern systems compatible with a modern network 
infrastmcture rather than forcing compatibility to legacy formats. Legacy formats, like 
the 240-bit data frame are not amenable to transport on the current data network, which 
transfers T-1 size data frames. Defining system interfaces that produce data in a form 
that can be transported by the network, irrespective of how it evolves, is an important 
step in modernizing the range. 

B. RECOMMENDATIONS 

The baekward compatibility strategy should be reviewed with a systems 
perspective starting with the interface control documents. Particular attention should be 
paid to data input and output rates and formats. If a devices requires input in a legaey 
data format, it needs to be used with middleware to eonvert data from the format used by 
the core network, because the legacy formats cannot be used directly on the network. 
Making a system that is inherently compatible with the range network convert its output 
to a legacy format is unnecessary beeause that data is reformatted for transport on the 
network. If the requirement for the legacy data standards is driven by other ranges that 
need to interface with the launeh ranges, the issue may need to be brought to the Range 
Commanders’ Council. Emphasis should be on putting the middleware at the device that 
consumes legaey formatted data rather than at the device that produces it. 

C. AREAS OF FURTHER RESEARCH 

The range has a significant network bandwidth demand for video that far exceeds 
the network bandwidth demands of the range safety requirements (Gillis, 2008). The 
range also records telemetry data for latter analysis and arehives other data. Arguably the 
range is basically an Automated Information System, which probably led to the ORD 
requirement for the range to be DoD GIG compliant. (Headquarters Air Force Space 
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Command, DRSR, 2003, Section 1.4.3.3). The range is also a real time sensor network 
with strict range safety timing requirements. Can these functions both be optimized on 
the same network? Does the AIS need for accessibility create vulnerabilities to the 
sensor net side? The current practice of using a dedicated command destruct circuit 
seems to be a reaction to such concerns. 

Another consideration is the extent to which some data, like telemetry data, is 
both range safety and customer data. For some operations the entire telemetry stream 
needs to be handled by the range safety systems to extract the data they need. This is the 
same telemetry data the customer wants. The Publish/Subscribe model appears to be able 
to handle a variety of subscriptions with a hierarchy of priority. This may allow both 
functions to work well together on the same network, especially if the telemetry data 
comes from the vehicle formatted in IP packets. The correct Quality of Service 
parameters could address the reliability requirements for range safety and the large 
network sized for AIS functions would have ample performance. 

There appears to be room for improving timeliness by examining the need to 
maintain legacy communications standards. The emphasis should be on interoperability 
with the network, rather than between the devices that produce data and the ones that 
consume it. Getting data from one to the other demands network compatibility, so the 
interface requirements need to reflect that. Further study along these lines should be 
done within the launch range and among all the ranges that need to interoperate. 
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